home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Network Support Library
/
RoseWare - Network Support Library.iso
/
pressgen
/
vlm.txt
< prev
next >
Wrap
Text File
|
1994-03-02
|
11KB
|
298 lines
C a s e S t u d y
Using the New Novell Netware Workstation VLMs February 14, 1994
_________________________________________________________________
Overview
--------
We recently installed a Netware 3.12 network, which came
with the new Netware Virtual Loadable Modules (VLMs) for
workstations. While the installation of the server and backbone
LAN went smoothly, the configuration and satisfactory operation
of the VLM workstations proved otherwise. We wish to share our
initial experience with VLMs with you, so that you may benefit
from what we have learned. We would appreciate any response you
may offer.
Who We Are
----------
My group designs, installs and supports relational database
management systems and related custom software applications for
client/server environments. To ensure an appropriate server and
network platform for these applications, we necessarily design,
install and support Novell-based LANs, and WANs.
Initial Problems With All VLM Workstations at This Site
-------------------------------------------------------
All workstations at the subject site are either PS/2s or AT
machines running either DOS 5.0 or 6.0. All are VGA or SVGA
machines, and the AT machines are mouse-equipped.
In summary, the VLM workstations were simply unstable. Here
is an outline of the problems we encountered at the startup of
operations.
ACCOUNTING SYSTEM: The vendor of this accounting system
emphasized the importance of correct FILES= settings in the
CONFIG.SYS of the workstation, and for FILES HANDLES for
Novell, to ensure stability. (Unfortunately, the vendor was
still in the Netware 2.X era regarding FILES HANDLES.)
Nonetheless, we ensured that each workstation had sufficient
FILES resources to avoid any problem here. Even so,
workstations would freeze, especially when printing within
the accounting system.
RDBMS: Accessing HELP menus at the workstation, especially for
script editing, caused the workstation to freeze and/or to "zap"
some TSRs. We also encountered "record lock" conditions,
followed by a loss of network connection.
RCONSOLE: "IPX Open Socket Failed" at loss of network
connection.
PRINT SCREEN: The workstation would freeze.
LANSIGHT: Screen images were contaminated, and we would lose the
USER TSR.
First a Brief Tutorial on Workstation Setup with VLMs
-----------------------------------------------------
For reasons wholly our own, we standardize on Hewlett-
Packards "16+" LAN cards. This site has a combination of PS/2s
and AT machines, but we will only address the AT machines. If
you want additional information on the setup of the PS/2s, we can
provide it.
There are two steps in setting up a VLM workstation.
[1] Use the setup disk which comes with the LAN card, and
configure the card in the workstation. Write down the
following settings at the conclusion of the card setup, as
you must specify these when installing the VLMs.
PORT =
DMA =
INT =
FRAME TYPE =
Note: The default Frame type for VLMs is 802.2,
NOT 802.3. Make sure you have the right frame type
for your network.
[2] Use the WorkStation Setup disk and DOS/AT disk which
comes with the Netware disks to configure and install the
VLMs. These do the following.
[a] Create the directory NWCLIENT on the workstation
hard drive.
[b] Create a NET.CFG file located in the NWCLIENT
directory, which contains the precise configuration
information for each workstation. (With more and more
components on PCs, chances are each workstation setup
will be different, so dont count on simply copying
the first setup into other workstations.)
[c] Add the line LAST DRIVE = Z to the CONFIG.SYS
file.
[d] Add the line @CALL C:\NWCLIENT\STARTNET.BAT to
the AUTOEXEC.BAT file.
The STARTNET.BAT file loads all files and drivers
needed to connect the workstation to the network. A
typical STARTNET.BAT file looks like this.
@echo off
c:
cd \nwclient
set nwlanguage=english
lsl
<card driver>
ipxodi
vlm
cd \
It uses a file called NET.CFG from the NWCLIENT
directory for configuration information. A typical
NET.CFG file looks like this. Note that the indentation
is essential.
Link Driver AM2100 <- card driver name
PORT 300
DMA 3
INT 10
FRAME Ethernet_802.3
Netware DOS Requester
FIRST NETWORK DRIVE = F
USE DEFAULTS = OFF
VLM = CONN.VLM
VLM = IPXNCP.VLM
(etc)
VLM = NETX.VLM
Now to the Problems, Causes and Remedies
----------------------------------------
The root problem with VLMs, as you may have begun to
suspect, is that they consume much more conventional memory in
DOS machines than the traditional network shells. In any robust
environment, this will likely cause certain applications to seize
memory, zapping TSRs and network drivers, knocking the
workstation off the network, and ultimately freezing the
workstation when they run out of memory.
THEREFORE, you MUST have a memory management capability,
such as QEMM or DOS 6.0/6.2s MemMaker, if you are even to
attempt running VLMs successfully.
FURTHER, you may find that some machines simply will not
run with the VLMs, no matter how hard you try. If so, you can usually
trace this to an inherent conflict between the LAN card, BIOS or bus
controller on the motherboard and the memory management system you
are attempting to use. Unless you are willing to replace the PC, you
will need a "blended" solution, as described below.
VLMs and Memory Management
--------------------------
There are three major issues to address when you tackle VLMs
and memory management.
[1] How much conventional memory you must free up will
depend on the mix of applications running on your network
and workstations, and their various "minimum" workstation
conventional memory needs. Regrettably, these are not
always evident. A good rule of thumb is that you should
have 550K or more of conventional memory when you are done.
If you have below 500K, you will likely have problems.
[2] What mix of TSRs, system drivers and network drivers
you can successfully load into and execute properly from
upper memory blocks (UMBs) will depend on each PC.
They are NOT all alike, and even the same "brand" works
differently with different CPUs/speeds, etc. (Here, too, you
can trace these differences to versions of motherboards, etc.)
A network driver comfortable in upper memory on one machine
will not load into an UMB on the next, and so on.
[3] The STARTNET.BAT file is embedded in the AUTOEXEC.BAT
file. QEMM will not even attempt to optimize the
workstation and network drivers here. We successfully
tricked QEMM by first moving the STARTNET command lines into
the AUTOEXEC.BAT, then optimizing, then copying the results
back into the STARTNET.BAT file. (We did not try MemMaker,
as we moved next to the solution described below.)
What To Do If You Have Problems with VLMs
-----------------------------------------
First of all, do your best to ensure the problem(s) you
encounter are related to the VLMs. To illustrate, we moved the
customers accounting system onto the network. While testing the
entry of a payments batch in the accounts payable module, it appeared
during the printing of the trial batch that while the batch total
was correct, the detail records were lost. We first suspected this
was caused by known bugs in the VLMs which show up during network
printing. It turned out that this was caused instead by an
unpublicized bug in the LAN pack from the accounting system vendor,
and an installable patch from them fixed this problem.
By all means, call Novells technical support group. They
are a breath of fresh air compared to other tech (un)support groups.
Those of you who fight the battles we fight every day know from whence
we speak.
If the problems you find surround printing on the network, try
Novells VLM update. You can download this self-extracting file,
called VLMUP.EXE, from Novells BBS, explode it in a temporary directory,
and follow the README instructions. These files contain BETA (at this
writing) VLM changes to overcome listed problems with the Netware Client
for DOS/Windows. We tried this, and while it improved the workstation
performance somewhat, it didnt solve our particular problems.
Given the machine types at our installation site, we were
unsuccessful in combining VLMs, memory management and applications.
Our solution was to fall back completely to Netware ODIs. You may
find that VLMs work fine on some machines, while the following ODI
solution may be required on others.
We obtained the latest from Novells BBS, by pulling down a
self-extracting file called DOSUP8.EXE. (We believe DOSUP9.EXE is
now the latest.) This file was copied into a DOSUP8 directory on the
server, and exploded. Then, we took the following steps with each
workstation.
[1] We created the local hard drive directory C:\LAN.
[2] We copied the following files from the DOSUP8 directory
into C:\LAN.
LSL.COM
IPXODI.COM
NETX.EXE
[3] We copied the LAN card driver to this directory. In
this case, the name of the LAN card driver was "AM2100.COM".
[4] Using DOS Editor, we created a NET.CFG file, which
contained the following. Note that the indentation starting
with Line 2 is required.
Link Driver AM2100
PORT 300
DMA 5
INT 10
FRAME Ethernet_802.3
[5] When we finished, the C:\LAN directory contained the
following files.
AM2100.COM
IPXODI.COM
LSL.COM
NETX.EXE
NET.CFG
[6] Next, we edited the AUTOEXEC.BAT file, and added these
lines. Note that the order is essential.
C:\LAN\LSL
C:\LAN\AM2100 <- the card driver
C:\LAN\IPXODI
C:\LAN\NETX
[7] Then, we used either QEMM or MemMaker to optimize
memory, depending on the workstation, and tested each
workstation to ensure that whatever the memory manager
loaded into UMBs was stable. If a workstation was not
completely stable, we customized its memory optimization
until everything worked in concert.
[8] Finally, we created a directory and subdirectories for
each workstation on the server, and copied the contents of
each LAN directory and associated CONFIG.SYS and AUTOEXEC.BAT
into these subdirectories. (Who wants to try to remember which
configuration worked with which workstation?!?)
Conclusions
-----------
While we wish otherwise, we are stuck with the apparently
never-ending battle of DOS conventional memory limitations and
conflicting hardware and software solutions. Hopefully, this case
study lends some useful insight, and helps some of you "make it work".
Your responses, critiques and questions will be welcomed.